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REMARKS 

The instant application includes Claims 1, 4 through 14, and 17 through 27. Claims 1, 
14, and 27 are the three (3) independent Claims. Claims 4 through 13 depend from Claim 1. 
Claims 17 through 26 depend from Claim 14. Claim 27 is newly added. 

New Claim 27 recites, inter alia, that the single character indicator comprises a single bit 
and that the single character indicator is outside of and separate from a substantive message. 
Support for this amendment is found at least on page 6, in FIG. 2, on page 4, line 28, and on page 
5, line 4 of the specification as originally filed. 

For example, at page 4, line 28, an embodiment of the single character indicator is 
identified. When the server computer 12 that is responsible for keeping the connection alive 
sends a predefined "no message" flag 16, 18, 20, the communication includes a single character 
or "0" that comprises a single bit. At page 5, line 1, when server computer 12 needs to send 
information to the client 10, the server computer 12 sends a predefined "message pending flag" 
22. Here, the communication includes a single character indicator "1" or a single character 
indicator that comprises a single bit. No new matter is introduced by way of this amendment. 
Although, the addition of this new claim is being done after a final rejection, Applicants contend 
that the addition of new Claim 27 does not raise any new issues that require fiirther consideration 
and/or search. Applicants request that this new Claim be entered After Final without the filing of 
a Request for Continued Examination. Acceptance of Claim 27 into the application is 
respectfiiUy requested. 

In the Action, Claims 1, 4, 5, 10 through 14, 17, 18 and 23 through 26 have been rejected 
under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent No. 6,721,286 to Williams, et al 
(hereinafter "Williams"). Applicants contend that Claims 1, and 14 are patentable over Williams 
since Williams does not disclose or suggest all of the elements of independent Claims 1, and 14. 
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In Williams, sessions are opened by issuing an Open request which can either be active or 
passive. See column 16, line 49 through 50. A passive Open request puts the session protocol 
into the Listen state during which it passively listens for a request to open a session from a 
remote host. The active Open request attempts to establish a session with a specific session 
protocol port at a remote host. See column 16, lines 49-55 and FIG. 6. 

For a session, the session protocol maintains no more than one transport message 
connection, but the session protocol may maintain more than one transport stream connection 
with the remote host. The session protocol multiplexes all additional Message Channels over the 
single message connection. 

All additional Stream Channels correspond directly to additional transport stream 
connections. The physical message connection is never closed during the lifetime of the session. 
See column 18, lines 18 through 44. If the session protocol's message connection fails, the 
protocol closes all transport connections, cancels all the listening and destroys the session control 
block. As mentioned, the session protocol will not close the session if the protocol stream 
transport connection fails. The reason for this is that a message connection is required for 
communication of all messages while a stream connection is only optional for some messages. 

If one side of a session crashes, the session may be left with the other side still active. 
This situation is termed a so called "half-open session". To ensure that the so called "half open 
sessions/connections" do not remain open and consume resources for an extended period of time, 
the session protocol sends keep-alive messages during long periods of inactivity in the session. 

If there has been no activity on any channel within the session for longer than ten 
minutes, the session protocol sends a keep-alive message or Null message. The session protocol 
sends the Null message to the other side over the message connection. If the message connection 
fails, the session protocol receives a disconnect notification from the underlying transport and the 
session is terminated. See column 18, line 61 through column 19, line 12. 
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The Office contends that the ''single character indicator" that is "outside of and separate 
from the substantive message" appears to be shown at column 19, line 9 as the so called keep 
alive or Null message. Applicants respectfully disagree and traverse the rejection as follows. In 
column 22 of Williams, the message layout and format is specified. In particular, every session 
protocol message is prefaced with a 20-byte session protocol header. See column 22, line 19 
through 20. A generic header that is used is shown in Fig. 1 1 of Williams. The header is for 
each specific message. See column 22, lines 19 through 20. Williams discloses that some fields 
of the header are needed in every message, while other fields of the header are only needed by a 
few messages. Williams discloses that all multi-byte words in a segment are transmitted across a 
network byte order which is in big-endian form. See column 22, line 3 1 . In bytes 0 and 1 of the 
header of the message, there is a 16-bit Control Bits field. 

The 16-bit Control Bits field occupies bytes 0 and 1 of the header or occupies a portion of 
the substantive message. Thus, Applicants contend that this Null or keep alive message is not 
"outside of and separate from a substantive message". Rather, the Null or keep alive message is 
encoded within the substantive message, i.e., in the header which is sent with each message. See 
column 22, line 19 through 20. 

Control Bit No. 5 of the Control Bits field is described as the Null (keep-alive) bit of the 
stream of bits that forms the 16-bit Control Bits field. It should be appreciated that the entire 16- 
bit Control Bits field that is in the header of the substantive message is sent, and not just a single 
control bit of the 16-bit Control Bits field. If a single bit was sent, the protocol would not be able 
to keep the message alive, and only a combination of control bits with the fifth Control Bits field 
set to 1 and all other bits therein set to their respective value defines the instant keep-alive 
message. An example of such a Null or keep alive message type is shown at column 22, line 67. 

Moreover, the header provides 16 control bits with each of the 16 control bits providing 
different indicators in the header such as "Establish Session or Channel" at Control bit 1, "Accept 
Session or Channel" at Control bit 2, "Reject Session or Channel" at Control bit 3, "Close the 
Session or Channel" at Control bit 4, "Message Information Directed to a Specific Channel" at 
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Control bit 6, "Gateway Broadcast or Reply" at Control bit 7, "Extended Header" at Control bit 8, 
and a "Fragment Flag" at Control bit 9. See column 22, lines 34 through 52. 

This is not a single character indicator (but a 16-bit wide field with numerous indicators) 
in contrast to the claimed invention. Moreover, the 16-bit wide field contains numerous amounts 
of defined values with numerous different indicators, and Williams does not disclose or suggest a 
single indicator. Moreover, such a lengthy message located in the header of a substantive 
message would defeat the purpose of the Applicants' server having push technology, since the 
single character indicator avoids firewall and security concems induced by non-standard 
communication. See page 3, lines 1 through 11 of Applicants' Specification. 

The Office contends at page 4 of the Action that a 16- bit field could be reasonably 
interpreted as a single character indicator. Applicants respectfully disagree. Even if all of the 
other control field bits were zeros, and the fifth control bit was assigned a value (1), each of the 
control bits of the 16-bit Control Bits field is a stream of data bits that would still be 
communicating other indicators (exclusive of the Null message), and each of the control bits of 
the stream of data bits would still be encapsulated in the message header of the substantive 
message. The instant single character indicator would not be recognized in the system of 
Williams and would be required to be assigned within the fifth control bit value defined in the 16 
Control Bits field in order to provide the null message within the context of a larger substantive 
message. 

Moreover, the purpose of the keep-alive message of Williams is to ensure that half open 
sessions/connections do not remain open and consume resources. See column 19, lines 1 through 
5. In contrast, the present disclosure includes that the single character indicator is used to 
maintain a healthy connection alive which it does by sending a predefined "No message Flag" 16, 
18, 20 such as using a single character "0" at a periodic time interval. The present disclosure also 
sends a predefined "Message Pending" flag 22 such as the single character 'V along the already 
established and maintained connection. 
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The present disclosure provides for a method and a system for using a standard 
communication protocol for implementing a server "push" technology and thereby avoids firewall 
and other security issues induced by non-standard communication. The present disclosure does 
not address any "half open" session/connection situation as in WilUams, and Applicants contend 
that such a half open connection is unnecessary with the "push" system of the present disclosure. 

The Office states at page 4 of the Action that the Applicants' specification does not 
indicate the size of the single character indicator in bits. Applicants respectfully disagree with the 
Office and state that an embodiment of the Applicants' single character indicator size is shown at 
least in one embodiment at page 3, line 7, page 4, line 28, page 5, line 4, page 6, line 3, and page 
6, line 19 and in Figs. 2 and 3 (a bit set to 0 or 1 defining the invention flags 16, 18, 20 and 22). 
The Office further states at page 4 of the Action that the specification does not indicate whether 
the single character indicator is encapsulated within a packet, frame, and cell, etc. that would 
include a header. 

In response. Applicants contend that clearly the single character indicator is not 
encapsulated within a substantive message as shown in Williams, and as referred to in the Action. 
Instead, the single character indicator is preestablished to indicate a non substantive message, and 
is outside of, and separate from, a substantive message. This promotes implementing server 
driven push technology, and avoids firewall and other security concerns induced by non-standard 
communication. Thus, reconsideration and withdrawal of the rejection of Claim 1 are respectfully 
requested. Claim 14 is patentable for reasons similar to those argued above for independent 
Claim 1. 

As such, for all these reasons, independent Claims 1 and 14 are believed to recite the 
present invention in terms which are not anticipated by Williams. Claims 4, 5 and 10 through 13 
depend from independent Claim 1, and Claims 17, 18 and 23 through 26 depend from 
independent Claim 14. Thus, each of these dependent claims are patentable over Williams for at 
least the same reasons discussed above for independent Claims 1 and 14. Accordingly, the 35 



09/928,667 



-11- 



U.S.C. § 102(e) rejection is believed to be overcome and withdrawal of this rejection is 
respectfully requested. 

The Action also rejects Claims 6 through 9 and 19 through 22 under 35 U.S.C. § 103 as 
being unpatentable over Williams. Claims 6 through 9 depend ftom independent Claim 1, and 
claims 19 through 22 depend from independent Claim 14. Thus, the foregoing arguments and 
patentable distinctions apply here. The cited art, Williams, does not make obvious the, . 
maintaining the connection . . , . . transmitting a single character indicator . . from the server to 
the client at short intervals; . . the single character indicator being outside of and separate from a 
substantive message", as recited in independent Claims 1 and 14. 

Instead, Williams uses 16 control bits in the message header of all messages to ensure that 
half open sessions do not remain open and consume resources. One of ordinary skill in the art 
would not be motivated to use Williams' 16-bit control bit field for maintaining the healthy 
connection in the present disclosure or change the 16-bit message header portion to a single 
character indicator that is separate from, and outside of, the substantive message as in the present 
disclosure to promote "push" technology. One of ordinary skill in the art would not apply the 16 
bit control field of Williams that uses "pull" systems in the control protocol to request information 
from the server to a "push" system of the present disclosure. Accordingly, the 35 U.S.C. § 103 
rejecfion of Claims 6 through 9 and 19 through 22 is believed to be overcome. Reconsideration 
and withdrawal of this rejection are respectfiilly requested. 

Newly added independent Claim 27 is patentable over the cited reference for reasons 
similar to those argued above for base Claims 1, and 14. 
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CONCLUSION 

In view of the above amendments and remarks, it is believed that all claims, 1, 4 through 
14, and 17 through 27 are in condition for allowance, and it is respectfully requested that the 
application be passed to issue. If the Examiner feels that a telephone conference would expedite 
prosecution of this case, the Examiner is invited to call the undersigned. 



Respectfully submitted, 

HAMILTON, BROOK, SMITH & REYNOLDS, P.C. 




Mary Lou WjCkimura 
Registration No. 31,804 
Telephone: (978) 341-0036 
Facsimile: (978) 341-0136 



Concord, MA 01742-9133 
Dated: ^-/^^ 



